1. Field of Art
This invention pertains in general to software application architectures, and in particular to architectures for developing applications comprising application components within multiple security domains.
2. Description of the Related Art
In organizations for which computer security is a high concern, such as in military or defense-related organizations, the organizations have traditionally chosen to structure their computer information systems as a set of security domains corresponding to different levels of security. Each domain, such as “Top secret,” “Secret,” and “Unclassified” domains, is a labeled collection of computer resources such as files, processes, and devices that share the same security classification label corresponding to a particular security level and are governed by rules that limit or prohibit communication or sharing with computing resources in other security domains having different classification labels. Each domain has a set of authorized users who may gain access to the resources associated with that domain. The domains are typically arranged in a hierarchy of security levels according to the Bell-LaPadula model, such that some domains are more secret than, or at least as secret as, other domains. Such domains are said to “dominate” the other domains. For example, a “Top Secret” domain corresponding to a particular high security level could dominate the “Secret” and “Unclassified” domains corresponding to lower security levels, and “Secret” could dominate “Unclassified.” (Domains may also be said to dominate themselves.) Information may be shared “upwards,” i.e. users authorized to access information in a higher secrecy domain may view information in lower secrecy domains without constituting a security problem, but information should not be shared “downwards.” For example, “Top secret” information should not be accessible from the “Secret” or “Unclassified” domains. A person, a program, or other entity is said to be “cleared” to access information at a given security level if that entity is authorized to view information at that level and any lower levels. For example, a person with authorization to access the “Top secret” level and all levels below it is said to have “Top secret clearance.” However, using traditional system designs, the domains are typically physically separated. Thus, for example, a user might be obliged to have multiple computer systems at the user's desk, one for each security domain, or to go to a separate office to access a different security domain.
Some conventional computing systems do permit multiple security domains to be accessed via a single hardware unit, such as by running multiple separate instances of an operating system on a single workstation, one instance per security domain. For example, such a workstation might run an instance of MICROSOFT WINDOWS at a “Top secret” level, another instance at a “Secret” level, and another instance at an “Unclassified” level. This simulates multiple, separate networked computers associated with different security domains and is referred to as a Multiple Independent Level Security (MILS) system. However, the various domains are logically isolated from each other, such that a user logged in to a system for one security domain cannot access resources from a different security domain. Users can (if authorized) switch between the different security domains of the MILS system and can run applications within each domain, but the applications are “single-level” —that is, they run only within a single domain of the MILS system and have no knowledge of, or access to, other domains. This inability to access information from different security domains makes MILS systems cumbersome and ineffective. For example, using a MILS system in which a user was logged into the “Top Secret” domain, the user could access files and messages associated with the “Top Secret” domain, but would be obliged to log in separately to the “Secret” domain to access files and messages associated with the “Secret” domain. Further, the user would have to access each security domain (e.g., each operating system instance) within its own separate window representing that domain, since the different domains cannot interact, much less comingle information from different domains within the same window.
A Multilevel Security System (MLS) provides the ability to access resources associated with one security domain from within a different security domain. For example, an MLS system will not only permit applications that are running at separate security levels to simultaneously share a monitor, keyboard, and mouse (for example), but will also permit an application with sufficient privileges to access data and services from multiple distinct domains. For example, an MLS desktop will display applications from multiple levels each in their own window on the desktop, as opposed to having them run in their own, separate, “virtual” desktop as in a MILS system). However, creating MLS-enabled applications that do not inadvertently compromise the security of the different domains can be difficult. One approach is for application creators to rely on trusted middleware that has been certified to manage the inter-domain communication in a manner that does not compromise security. However, even trusted middleware can pose a security threat in the case of systems where intruders may gain administrative privileges. This is particularly the case for client systems, where security settings are typically less rigorously administered than on server systems, and where direct access to the system is much more common than with servers, which can generally only be accessed remotely.
Additionally, many MLS-enabled applications rely on the underlying operating system to itself provide basic MLS functionality, such as SOLARIS system calls that change the security label identifying the domain with which a particular resource is associated. However, many popular operating systems, such as MICROSOFT WINDOWS, do not provide the mechanisms, such as labeling files and processes, that are used to implement MLS functionality. Thus, these “single-level” operating systems cannot run MLS applications, and users wishing to use MLS applications are therefore limited to operating systems that provide the requisite MLS functionality. This restriction is a disappointment to many users, who would prefer to be able to use their favorite operating systems and the associated applications.